Day 1｜AI Security 是什麼？30 天打造自己的 AI Security Lab

前言

近幾年生成式 AI 快速發展，從單純的聊天機器人，到現在結合 RAG、Tool Calling、AI Agent，AI 已經不只是「回答問題」，而是逐漸能夠讀取資料、呼叫工具，甚至代替使用者執行操作。

但當 AI 能做的事情越來越多，一個問題也開始變得重要：

AI 也需要做資安嗎？

過去談到資訊安全，我第一時間想到的可能是網路攻擊、弱點、IDS、Log、SIEM 等傳統資安技術。

但如果今天系統中多了一個 LLM，攻擊方式可能就不太一樣了。

例如：

• 使用者能不能透過特殊 Prompt 改變 AI 原本的行為？
• System Prompt 真的能被當成秘密嗎？
• AI 有沒有可能把不該公開的資料回答出來？
• 如果 AI 可以讀取外部文件，文件本身會不會變成攻擊來源？
• 如果 AI Agent 可以呼叫工具，攻擊者有沒有可能誘導 AI 執行不該執行的操作？

這些問題，就是這次 30 天想要實際探索的內容。

什麼是 AI Security？

AI Security 涵蓋的範圍其實非常廣。

如果單純從這次專案的角度來看，我會把它理解成：

保護 AI 系統，避免模型、資料、輸入、輸出以及 AI 可以執行的操作，被攻擊者利用或操控。

傳統 Application 大致可能是：

User
  ↓
Application
  ↓
Database

加入 LLM 後，架構開始變成：

User
  ↓
Application
  ↓
LLM
  ↓
Response

再進一步加入現在常見的 RAG 與 Agent：

                User
                  ↓
            AI Application
                  ↓
                 LLM
             ↙          ↘
           RAG          Agent
            ↓             ↓
        Vector DB        Tools

這時攻擊面就不再只有 Application 本身。

可能還包含：

User Input
System Prompt
LLM Output
RAG Document
Vector Database
Agent
Tool
Sensitive Data

也就是說：

AI Application 的安全，不等於只有 LLM 本身的安全。

我們真正需要保護的是 LLM 周圍的整個系統。

AI 到底會遇到哪些攻擊？

目前已經有專門針對生成式 AI 與 LLM Application 的安全研究與風險分類。

例如 OWASP GenAI Security Project 發布的 LLM Top 10，就整理了大型語言模型應用的重要安全風險，其中包含 Prompt Injection、Sensitive Information Disclosure、Improper Output Handling、Excessive Agency、System Prompt Leakage，以及 Vector / Embedding 相關弱點等。

而這些並不只是「模型回答錯誤」而已。

當 LLM 開始連接資料與工具之後，安全問題可能從：

AI 說了不該說的東西

進一步變成：

AI 做了不該做的事情

這也是我認為 AI Security 很有趣的地方。

這 30 天要做什麼？

這次我不打算只整理 30 天的 AI Security 理論。

我的目標是：

自己打造一套 AI Security Lab。

簡單來說，就是先建立一個 AI Application，然後自己當攻擊者攻擊它，再切換成防守方建立安全機制。

整個實驗流程預計會是：

建立 AI
   ↓
攻擊 AI
   ↓
觀察問題
   ↓
建立防禦
   ↓
再次攻擊
   ↓
記錄 Security Event
   ↓
監控攻擊
   ↓
自動化測試

希望每一個安全問題都不是只有：

「Prompt Injection 是什麼？」

而是實際做到：

Attack
  ↓
Attack Successful

接著再加入防禦：

Attack
  ↓
Security Gateway
  ↓
BLOCKED

最後比較攻擊前後的差異。

AI Security Lab 的初步架構

目前預計的最終架構如下：

                       User
                         │
                         ▼
               ┌───────────────────┐
               │ AI Security       │
               │ Gateway           │
               │                   │
               │ Input Filter      │
               │ Threat Detection  │
               │ Data Protection   │
               │ Output Filter     │
               │ Permission Check  │
               └─────────┬─────────┘
                         │
                         ▼
                   ┌──────────┐
                   │   LLM    │
                   └────┬─────┘
                        │
               ┌────────┴────────┐
               ▼                 ▼
             RAG               Agent
               │                 │
               ▼                 ▼
          Vector DB             Tools

                        │
                        ▼
                 Security Log
                        │
                        ▼
                      Wazuh
                        │
                        ▼
                 Security Alert

當然，Day 1 還不會一次把這些東西全部做出來。

接下來 30 天會逐步把每個元件加入這個 Lab。

第一階段：先建立攻擊目標

Day 1～Day 5 會先建立最基本的 LLM Application。

預計包含：

Ollama
Python
FastAPI
Local LLM
Security Logging

先確保我們有一個可以正常使用的 AI。

因為：

沒有 Target，就沒有 Attack。

第二階段：開始攻擊自己的 AI

Day 6～Day 10 會開始進入攻擊實驗。

包含：

Prompt Injection
Jailbreak
System Prompt Leakage
Sensitive Information Leakage
Attack Test Suite

這個階段的目的不是單純追求「破解 AI」，而是觀察：

LLM 在什麼情況下會違反我們原本設計的安全假設？

第三階段：建立 AI 防線

知道怎麼攻擊之後，Day 11～Day 16 開始建立自己的 Security Gateway。

預計加入：

Input Filtering
Threat Detection
Prompt Injection Detection
Sensitive Data Protection
Output Filtering
Risk Scoring

架構開始變成：

User
  ↓
Security Gateway
  ↓
LLM

然後重新執行之前的攻擊。

看看原本：

ATTACK SUCCESS

能不能變成：

ATTACK BLOCKED

第四階段：把 AI Security 接到傳統資安

這也是這次我很想實驗的一部分。

Day 17～Day 20 預計將 AI Security Event 記錄成結構化 Log，再串接 Wazuh。

例如：

{
"event_type": "prompt_injection",
"risk": "HIGH",
"action": "BLOCK",
"timestamp": "..."
}

最後希望做到：

Prompt Injection
       ↓
Security Gateway
       ↓
Security Event
       ↓
Wazuh
       ↓
🚨 Alert

也就是把：

AI Security

跟：

Logging / Detection / SIEM

結合起來。

第五階段：RAG 與 AI Agent Security

到了後半段，攻擊面會再擴大。

首先加入 RAG。

這時攻擊不一定來自使用者：

Attacker
   ↓
Prompt
   ↓
LLM

也可能藏在外部文件：

Malicious Document
        ↓
       RAG
        ↓
       LLM

接著再加入 AI Agent。

當 AI 擁有 Tool Calling 能力之後：

LLM
 ↓
Tool
 ↓
Action

我們面對的問題就從：

「AI 會回答什麼？」

變成：

「AI 被攻擊之後，可以做什麼？」

因此後續也會實作 Tool Permission、Allow / Deny 等安全控制。

最後：用自動化攻擊驗證防線

最後幾天會把前面所有攻擊整理成自動化 Security Test。

理想中的最終結果大概會像：

====================================
       AI SECURITY TEST REPORT
====================================

Prompt Injection       BLOCKED
Jailbreak              BLOCKED
Prompt Leakage         BLOCKED
Sensitive Data Leak    BLOCKED
RAG Injection          BLOCKED
Agent Tool Abuse       DENIED

------------------------------------
Defended: 6 / 6
====================================

當然，實際結果不一定會這麼完美。

甚至可能出現：

False Positive
False Negative
Defense Bypass

但我覺得這反而才是這個 Lab 最有價值的地方。

因為資安防禦並不是寫一個 if 就代表安全了，而是要透過不斷測試，才能知道防禦到底有效到什麼程度。

為什麼想做這個系列？

我過去接觸過一些 AI 與資訊安全相關技術，也實作過 Wazuh、Log 分析、機器學習等內容。

因此這次希望不要只是重新整理以前學過的東西，而是把原本的資安基礎延伸到現在快速發展的生成式 AI。

我希望透過這 30 天回答一個問題：

如果今天真的要保護一套 LLM Application，我可以怎麼做？

所以這次會盡量以：

實作 → 攻擊 → 防禦 → 驗證

作為每篇文章的核心。

Day 1 小結

今天還沒有開始寫 AI Security 的程式。

但我們先確定了接下來 30 天的 Target：

打造一套可以被攻擊、可以防禦、可以監控，也可以重複測試的 AI Security Lab。

接下來會從最基本的環境開始。

下一篇：

Day 2｜用 Ollama 建立本地 LLM 實驗環境